>>>>> "hoodr" == hoodr <hoodr@hoodr.slip.netcom.com> writes: >> Second question: How can I write a program that keeps the >> LD_LIBRARY_PATH variable from being exploited? i.e. the SUN >> 'login' bug where LD_LIBRARY_PATH got exploited. I would ASSUME I >> could prevent this by doing something like: >> putenv("LD_LIBRARY_PATH"), but that just seems too simple to be a >> true fix. (If it's not complex, it's not right? :) hoodr> Don't assume that LD_LIBRAY_PATH is the only variable you hoodr> have to worry about. I was able to easily break "sudo" with hoodr> the LD_PRELOAD variable (we've since fixed it by supplying a hoodr> brand new environment, instead of re-using the old one). hoodr> A strings on /usr/lib/ld.so, show the following items which hoodr> are most likley environment variables: LD_LIBRARY_PATH hoodr> LD_TRACE_LOADED_OBJECTS LD_PROFILE LD_PRELOAD hoodr> LD_SYMBOLS_PUBLIC hoodr> Of course only LD_LIBRARY_PATH seems to be documented in the hoodr> man pages. Maybe someone from Sun can comment on what the hoodr> rest of these do (please?) >> From experimentation, the LD_PRELOAD variable should point to a hoodr> library (not a directory of libraries). That library will be hoodr> loaded before the standard library path (or LD_LIBRARY_PATH) hoodr> is searched. LD_PRELOAD allows you to override certain symbols from a library without having to provide teh entire library. Great for shipping quick bugfixes and economizing on space. -Rens